1. Field of the Invention
The present invention relates to transaction processing.
2. State of the Art
Transaction processing using a point-of-sale (POS) terminal is well-known. Other types of transactions may be non-financial. In the area of physical security, for example, terminals may be used by patrolmen to check in, producing evidence of their having been in the required place at the required time. Terminals may also be used in the healthcare industry, for example, to produce a record of what medical personnel have attended a patient at what times, or for myriad other purposes. Transaction processing is used generally herein to refer to the use of a transaction terminal to read, and possibly to write, a record-bearing medium such as a credit card, an ID card, a smart card, etc. The transaction terminal may use a contact or a contactless reading mechanism. In the case of smart cards, for example, a contactless radio interface of a type known in the art may be used.
The present invention will be described largely in terms of POS transactions, since this type of transaction is most familiar.
The approval and “settlement” process for POS transactions involves various parties and various steps. Briefly, the transaction terminal receives card data and purchase amount data and sends it through a communications network to a transaction processing center (“transaction processor,” “front-end processor,” or “processor”). The transaction processing center switches the transaction to an association (e.g., Visa, Mastercard, etc.) acting on behalf of an issuing bank. Assuming that the transaction is authorized by or on behalf of the issuing bank, an authorization message is sent back through the transaction processing center and the communications network to the transaction terminal. If the transaction is authorized, “capture” follows in which information from the successful authorization is used to charge the authorized amount of money to the card. If goods are returned after the transaction has been captured, a “credit” is generated.
Settlement involves a merchant bank and an acquiring bank. The merchant bank has contracted with the merchant to enable the merchant to accept card transactions. The acquiring bank processes merchants's card transactions through the financial network on behalf of merchant banks (although in some instances the acquiring bank and the merchant bank may be the same). During settlement, captures and credits, usually accumulated into a “batch,” are submitted from the merchant to the transaction processing center and on to the issuing and acquiring banks. As part of the settlement process, a “direction letter” may be sent to the U.S. Federal Reserve's Automated Clearing House (ACH) network, advising it as to what debits and credits need to occur in order to complete the transactions in the batch. The card issuer is debited the amount of the sale and the merchant's acquiring bank is credited a like amount. The merchant's acquiring bank then credits the merchant's checking account for the amount of the sale less any fees the merchant has agreed to pay for such service.
Referring to FIG. 1, in the past, transaction terminals have typically been connected through a dial-up connection, through the PSTN (public switched telephone network) to a packet switched data network (e.g., an X.25 network) to a transaction processor. The transaction processor is connected in turn to various issuers (e.g., Visa, Mastercard, Discover, etc.) and to various acquiring banks.
Recently, a transaction terminal has been introduced that has a wireless modem—in particular a CDPD (cellular digital packet data) modem—that may be used to establish a connection to a CDPD network, bypassing the PSTN with its accompanying delays and charges. Such an arrangement is shown in FIG. 2. The transaction terminal connects wirelessly to a wireless network such as a CDPD network. The CDPD network includes multiple Mobile Data Base Stations (MDBS) connected to a Mobile Data Intermediate Station (MDIS). The MDIS is connected to a transaction processor via a Frame Relay connection. Frame Relay is used because it is much faster than an X.25 connection.
The system of FIG. 2 suffers various disadvantages. In general, the system does not scale well to meet the needs of “distributed commerce” (or “mobile commerce”). Distributed commerce may be distinguished from e-commerce by a greater element of human involvement. Hence, whereas in e-commerce goods or services are ordered and paid for on-line, in distributed commerce, goods or services may be ordered in person and paid for by tender of a credit card or other non-cash payment medium, as opposed to the submission by the consumer (e.g., Web submission) of credit card information or the like. Examples of distributed commerce include such things as flagging a cab and, at the desired destination, paying by credit card, or phoning in an order for pizza and, at the time of delivery, paying by credit card. Other examples of distributed commerce include quick service restaurants, taxi and limousine services, delivery-based businesses, stadium concessions, stand-alone kiosks, and mobile businesses generally.
Like e-commerce, underlying characteristics of distributed commerce should be user convenience, greater satisfaction of demand, and vendor efficiency. However, various impediments hamper distributed commerce. Whereas the “plumbing” for e-commerce (i.e., the Web) has become almost universally established, the plumbing for distributed commerce remains ad hoc. A vendor must invest in terminal equipment and terminal software/firmware, enter into a subscription agreement with a wireless carrier, and, perhaps most importantly, ensure that a transaction processor is capable of receiving transactions through the wireless infrastructure, or is willing to invest to create such wireless capability. In the prior art system of FIG. 2, for example, transaction processors are typically not equipped to handle Frame Relay traffic, requiring that a new “front end” be provided.
Furthermore, a vendor's equipment, representing a substantial investment, may rapidly become obsolete. That is, in FIG. 2, because intelligence is “hardwired” into the transaction terminals, the transaction terminals themselves must be replaced, retrofitted or reprogrammed to accommodate new technologies (to accommodate ATM cards in addition to credit cards, to cite a historical example).
Also, in prior art systems, terminal management is cumbersome and labor-intensive. Activating or deactivating a terminal is typically a laborious paper-based process that takes days or weeks. Keeping transaction terminals up and running is also problematic. The only way for a malfunctioning terminal to be identified and fixed is for it to be reported by the merchant, in response to which a service call is scheduled. Except in the most trivial cases, service usually entails replacing the transaction terminal and sending the faulty unit to a service center.
Moreover, in prior art systems, reporting is paper-based at intervals (e.g., monthly) in a fixed (not customizable) format.
Furthermore, today's hard-wired transaction terminals are relatively inefficient in their use of bandwidth.
Hence, although distributed commerce, like e-commerce, should be characterized by efficiency, flexibility and adaptability to rapid change, presently it is not.
What is needed, then, is a flexible distributed commerce system architecture that is highly efficient, that readily allows for new services to be offered, and that accommodates the existing transaction processor infrastructure.